perm filename SCU[P,JRA]1 blob
sn#441450 filedate 1979-05-17 generic text, type C, neo UTF8
COMMENT ā VALID 00005 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00005 00003
C00011 00004
C00013 00005
C00017 ENDMK
Cā;
Outline of General Philosophy
Both educational and industrial computer systems projects suffer from a
common malady: inadequately prepared programming staffs. This results
from a general misconception concerning the difficulty of programming;
frequently one hears statements expressing the sentiment that "anyone can
program." Of course that opinion is as accurate as "anyone can write a
poem." Our argument therefore involves a perspective on improving the
quality of programming and the programming process, rather than approaches
to the mechanics of learning the syntax of a particular language. The
former is an important facet of a university education in modern computer
science; the latter is not.
In a field with growth as rapid as that of computer technology a
university must be prepared to educate students in fundamental ideas as
well as expose them to current technology; for otherwise their education
will be obsolete even before they graduate. This is well understood in the
hardware field; this area has a substantial background to draw from in the
physical sciences. However, the situation is not so well developed in the
software domain. There is no historical precedent for handling problems
with the complexity of modern computer systems. Current efforts in
"programming methodology" represent initial attempts to come to grips with
these problems. Unfortunately many of the approaches involve only
syntactic or superficial solutions, restricting the expressibility of the
programming languages (and therefore the programmer) rather than
addressing the problem as a semantic one requiring an education in the
ways of thinking about complexity coupled with a collection of computer
tools which expands the programmer's expressibility.
What a University Computing Facility Should Represent
A university program which involves technology must be a model of how
things should be done, not how things are done. Alas, most computing
centers fail this miserably. As a result, students are still trained to
think and act about computing in fashions which were current twenty years
ago --batch processing, card input, paper output. This is a major
difficulty: the complexity and expectations of software products has
increased phenomenally. Unfortunately, the way we deal with computers has
changed very slightly; batch processing is faster, and we may use a "glass
teletype" to prepare the input and receive the output, but the general
paradigm still holds. Until very recently, such behavior could be excused
on financial grounds; only very few research establishments could afford
to develop and support quality tools, and only then for a select number of
individuals. Technology has changed that; even contemporary eight-bit
microprocessors can support reasonably robust programming environments.
That is the lesson in the success of personal computing and BASIC. An
"inelegant" language in an attractive package has done wonders in
de-mystifing computers.
The university role in computing can take several further lessons from
this experience. It is the quality of the tools which make the computing
environment either friendly or hostile. Most computing environments are
quite hostile; this makes for slow, unsatisfactory development; it
constrains the programming process to the point that creativity suffers.
That is hardly an atmosphere in which we should expect to develop our best
software people. Therefore the center should be exemplar in the quality of
the general programming environment. This includes programming tools like
general purpose display editors which allow text manipulation superior to
that currently available with hardcopy. Such editors have been in common
use since 1965 at the Stanford Artificial Intelligence Laboratory; their
use has spread through the AI community. What is new is that recent
technology has made this display philosophy economically viable. What is
needed is the realization that such tools exist and can improve the
programming process.
Further, the center should develop and support a student environment which
reinforces the methodological concepts which aid in creating, modifying,
and maintaining large complex software projects. Again, many of the
experiences of the AI community are applicable here. The complexity of AI
programs is rivaled by few other software efforts; the success of these
programs is a direct result of the quality of their tools. The environment
of a conventional personal computer pales in comparison to that
experienced by an AI researcher. Such environments are still expensive,
yet, in a few years, technology will again allow economical development of
such systems. (The results of Xerox's Palo Alto Research Center are
beginning to bear this out.)
Therefore the university role must be to expose the students to this "high
technology software", while giving them the intellectual education and
training to apply it wisely. It is this area which is most overlooked:
high quality tools cannot be used effectively by untrained individuals. A
programming methodology which develops a sense of maturity within the
individual is an integral part of the program. The current trends toward
language-enforced discipline are only short-term solutions which may do
more harm than good.
Conclusions
Santa Clara University is in an enviable position. It is in the heart of
the most technologically advanced part of the world. Its computer science
program can therefore both draw from the richest well of talent and at the
same time influence the future course of software development. This
valley is reknowned for its hardware development; its software, and that
of the industry in general, is a wasteland. An agressive program is
needed; it will do well.
In this brief outline I have discussed a general philosophical view of
computing and university education. I have not touched on the relationship
between education and a research facility, though I feel that it is
important to commingle the facilities and the personnel. Further, I have
not delved into a detailed plan that would support such a venture. If
there is interest in discussing details I would be quite pleased to
describe a concrete proposal. You may contact me at the addresses below.
Sincerely yours,
John R. Allen
18215 Bayview Dr.
Los GAtos, Ca 95930
(408)353-2227
Signetics Corp.
811 E. Arques Ave. MS.38
Sunnyvale, Ca 94086
(408)739-7700 x6304
Roger:
I am sorry to be so impatient about our arrangements, but time IS of the
essence. If I cannot feel that I can complete this project in a timely
and professional fashion, I will drop it; a date for that decision is
close at hand.
Following are some general questions and points which should be resolved
before we are to sign an agreement: (the order is totally random)
1. I assume that we will incur no liabilities due to a customer's use (or
misuse) of the product. Our responsibilities are restricted to producing a
quality product and fixing any bugs which occur.
2. Will the name of our partnership be associated with the software you
release?
3. Will the money be made available at the time the agreement is signed?
4. How soon after the signing will the machines be available?
5. Will the necessary software be included with the machines? (for
example: assembler, C, word processor, trace package, and editors
(teco-like and display-oriented)?
6. Do you have a conversion program which will take Intel formatted
floppies to your format?
7. Is there an extra RS-232 port available on the machines; if not, can we
get one included? Similar question about a PROM burner.
8. What are the dimensions of the new dazzler? If the dimensions are
around 264x480 it could be quite useful (for both parties)
9. What kind of assistance can we get on the production of the manual?
Proof reading? copy-editing?
10. We must have some agreement about the maintenance of the hardware. If
something malfunctions before the software delivery date, we must have
timely repair or replacement. Similarly some decisions must be made about
hardware maintenance during our period of software maintenance.
One final question: what is your assessment of the LISP market? i.e., how
many copies do you expect to sell? Probably other questions will come up,
but hopefully this list will cut down some of the iterations. The prospect
of developing a small, quality LISP system is exciting; however that
excitement is dampened as the end of September gets closer. A bad LISP is
worse than no LISP.